Writing a status update at 3am

It is 3am, the checkout API is returning 502s, and the on-call engineer has two jobs at once: fix it, and tell people. The second job is the one that gets skipped, and it is the one customers remember.

We read a few hundred public post-mortems while building status pages. The good status updates had three things in common, and none of them was eloquence.

1. A template, decided in daylight

Nobody writes well at 3am. The teams that communicate well during incidents decided what an update looks like weeks earlier, and the on-call engineer fills in blanks. Ours is four lines: what is affected, what customers will see, what we are doing, when we will update next. The last line is the one people forget and the one that matters most.

2. A rule about timing, not about certainty

The worst updates are the ones that never come because the engineer was waiting to know something. The fix is a rule that removes the choice: post within five minutes of the incident opening, and every twenty minutes after that, whether or not anything has changed. "We are still investigating and will update by 03:40" is a perfectly good update. Silence is not.

3. Permission to say 'we do not know yet'

An update that guesses at a cause and turns out wrong costs more trust than one that admits uncertainty. Give the on-call engineer explicit permission, in the runbook, to write "cause not yet identified". It reads as competence, because it is.

What Carbon does for you

When a monitor fails, the incident it opens posts the first update to your status page for you: the affected components, the time, and a promise of the next update. The engineer edits the wording if they want to and otherwise gets on with the fix. Subscribers to the affected components get the email; nobody else does. The resolution posts when the monitor recovers, and the incident timeline becomes the post-mortem's first draft.

None of that makes you a better writer at 3am. It just means you do not have to be one.